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■ We give a polymorphic account of the relational algebra. We in- 
troduce a formalism of "type formulas" specifically tuned for rela- 
tional algebra expressions, and present an algorithm that computes 

^ ' the "principal" type for a given expression. The principal type of 

an expression is a formula that specifies, in a clear and concise man- 
ner, all assignments of types (sets of attributes) to relation names, 
^ ' under which a given relational algebra expression is well- typed, as 

■ well as the output type that expression will have under each of these 
assignments. Topics discussed include complexity and polymorphic 
expressive power. 



1 Introduction 

The operators of the relational algebra (the basis of all relational query lan- 
guages) are polymorphic. We can take the natural join of any two relations, 
regardless of their sets of attributes. We can take the union of any two rela- 
tions over the same set of attributes. We can take the cartesian product of 
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any two relations having no attributes in common. We can perform a selec- 
tion aA<B on any relation having at least the attributes A and B. Similar 
typing conditions can be formulated for the other operators of the relational 
algebra. When combining operators into expressions, these typing conditions 
can become more involved. For example, for the expression 

(JA<5{r N s) M ((r x u) - v) 

to be well-typed, the attribute A must be an attribute of r or s (or both). 
But if it is an attribute of r, then it must also be one of v. Moreover, by the 
subexpression [r x u) — v, the relation schemas of r and s must be disjoint, 
and their union must be the type of v. 

A natural question thus arises: given a relational algebra expression e, 
under which database schemas is e well-typed? And what is the result rela- 
tion schema of e under each of these assignments? This is nothing but the 
relational algebra version of the classical type inference problem. Type infer- 
ence is an extensively studied topic in the theory of programming languages 
fl], 1^, |, |15|, H, and is used in industrial-strength functional programming 



languages such as SML/NJ p6|] . 

Doing type inference for some language involves setting up two things. 
First, we need a system of type rules that allow to derive the output type of a 
program given types for its input parameters. Typically such an output type 
can only be derived for some of all possible assignments of types to input 
parameters; under these assignments the program is said to be well-typed. 
Second, we need a formalism of type formulas. A type formula defines a 
family of input type assignments, as well as an output type for each type 
assignment in the family. Every typable program should have a principal 
type formula, which defines all type assignments under which the program 
is well-typed, as well as the output type of the program under each of these 
assignments. The task then is to come up with a type inference algorithm 
that will compute the principal type for any given program. 

In this paper, we do type inference for the relational algebra. The re- 
lational algebra is very different from the programming languages usually 
considered in type inference; two fundamental features of such languages, 
higher-order functions and data constructors (function symbols) are com- 
pletely absent here. On the other hand, the set-based nature of relation 
types, and the particulars of the standard relational algebra operators when 
viewed polymorphically, present new challenges. As a consequence, our for- 
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malism of type formulas is drastically different from the formalisms used in 
the theory of programming languages. 

Our main motivation for this work was foundational and theoretical; after 
all, query languages are specialized programming languages, so important 
ideas from programming languages should be applied and adapted to the 
query language context as much as possible. However, we also believe that 
type inference for database query languages is tied to the familiar principle 
of "logical data independence." By this principle, a query formulated on the 
logical level must not only be insensitive to changes on the physical level, but 
also to changes to the database schema, as long as these changes are to parts 
of the schema on which the query does not depend. To give a trivial example, 
the SQL query select * from R where A<5 still works if we drop from R 
some column B different from A, but not if we drop column A itself. Turning 
this around, it is thus useful to infer, given a query, under exactly which 
schemas it works, so that the programmer sees to which schema changes the 
query is sensitive. 

Some recent trends in database systems seem to add weight to the above 
motivation. Stored procedures are 4GL and SQL code fragments stored 
in database dictionary tables. Whenever the schema changes, some of the 
stored procedures may become ill-typed, while others that were ill-typed may 
become well-typed. Knowing the principal type of each stored procedure 
may be helpful in this regard. Models of semi- structured data |^ loosen 
(or completely abandon) the assumption of a given fixed schema. Query 
languages for these models are essentially schema- independent. Nevertheless, 
as argued by Buneman et al. [^, querying is more effective if at least some 
form of schema is available, computed from the particular instance. Type 
inference can be helpful in telling for which schemas a given query is suitable. 

Ohori, Buneman and Breazu-Tannen were probably the first to introduce 
type inference in the context of database programming languages, in their 



work on the language Machiavelli |Tl|, |T0|. Machiavelli features polymorphic 



field selection from nested records, as well as a polymorphic join operator. 
However, the inference of principal types for full-fledged relational algebra 
expressions was not taken up in that work. We should also mention the 
work of Stemple et al. [Ill], who investigated reflective implementations of 



the polymorphic relational algebra operators. 

Other important related work is that on the extension of functional pro- 
gramming languages with polymorphic record types. Some of the most so- 



phisticated proposals in that direction were made by Remy |12, 13|. This 
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work adds record types to the type system of ML, featuring polymorphic field 
selection and record concatenation. While this system captures many realis- 
tic functional programs involving records, it cannot express the conditions on 
the types of relations implied by certain relational algebra expressions, such 
as the example we gave earlier. Notably constraints such as set disjointness 
(needed for the operator x) or set equality (for the operator U), cannot be 
expressed in other systems. The reason is probably the additional concern 
of these systems for subtyping: a program applicable to records of a certain 
type should more generally be applicable to records having all the fields of 
that type and possibly more. This is clearly not true for relational algebra 
expressions. 

If one is only interested in deciding whether a given relational algebra 
expression is typable (i.e., whether there exists at least one schema under 
which the expression is well-typed), we show that this problem is in the 
complexity class NP. 

In a final section of this paper, we formally define the notion of poly- 
morphic query. Using our type inference algorithm, we prove that various 
operators usually considered "derived," because they can be simulated using 
the standard relational algebra operators (e.g., semijoin), can not be simu- 
lated in a polymorphic way. Thus, our work also brings up new issues in the 
design of appropriate polymorphic query languages. 

2 Preliminaries 

2.1 Schemas, types, and expressions 

Assume given sufficiently large supplies of relation variables and of attribute 
names. Relation variables will be denoted by lowercase letters from the end 
of the alphabet. Attribute names will be denoted by uppercase letters from 
the beginning of the alphabet. 

A schema is a finite set S of relation variables. A type is a finite set r of 
attribute names. Let <S be a schema. A type assignment on S is a. mapping 
T on S, assigning to each r e 5 a type T(r). So, we have split the usual 
notion of database schema, which specifies both the relation names and the 
associated sets of attributes, in two notions. 

The expressions of the relational algebra are defined by the following 
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grammar: 

e r 

I (e U e) I (e - e) I (e M e) I (e X e) 

I (ye(Ar,...,An){e) I 7rAi,...,A„(e) | pA/s(e) | 7rA(e) 

Here e denotes an expression, r denotes a relation variable, and A, B, and 
Ai denote attribute names. The 6 denotes a selection predicate. 

The schema consisting of all relation variables occurring in expression e 
is denoted by Relvars{e). 

2.2 Well- typed expressions 

Let 5 be a schema, e an expression with Relvars{e) <^ S,T a type assignment 
on S, and r a type. The rules for when e has type r given T, denoted by 
T h e : r, are the following: 

r (r) = r r h ei : r T h 63 : r T h ei : r T h ea : r 
T \- r : T T h (ei U 62) : r T h (ei — 62) : r 

T h ei : Ti T h 62 : r2 T h ei : ri T h 62 : r2 ri fl r2 = 
T h (ei M 62) : Ti U Ta T h (d x 62) : Ti U Ta 

Tl-e:r Ai,...,yl„er T h e : r Ai,...,A„er 

(Te(Ai,...,A„)(e) : T Th 7rA,,...,A„(e) : {Ai,... 

Tl-e:r Aer T h e : r Aer 

T^PA/B{e) : (t-{A})U{S} rh7fA(e) :r-{A} 

We have a first basic definition: 

Definition 1 Let e be an expression and let T be a type assignment on 
Relvars{e). If there exists a type r such that T h e : r, we say that e is 
well-typed under T . 

Note that in this case r is unique and can easily be derived from T by 
applying the rules in an order determined by the syntax of the expression e. 
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2.3 Semantics 



We assume given a universe U of data elements. 

Let r be a type. A tuple of type r is a mapping t on r, assigning to each 
A E T a. data element t{A) G U. A relation of type r is a finite set of tuples 
of type T. 

Let 5 be a schema, and let T he a type assignment on S. A database of 
type T is a mapping D on S, assigning to each r G iS a relation D(r) of type 
r(r). 

The semantics of well-typed relational algebra expressions is the well- 
known one. If T h e : T, and D is a database of type T, then the result of 
evaluating e on D is a relation of type r defined in the well-known manner. 
The only operator worth mentioning is perhaps the not so usual tta, which 
projects out the attribute A, leaving all others intact. 

At this point a remark is in order concerning the non-redundancy of the 
set of relational operators we consider. We have included both the natural 
join IXI and the cartesian product x, and also both the standard projection 
T^Ai,...,An the "complementary" projection tt^. It is well known that if 
the type assignment is fixed and known, 1X1 can be simulated using x (plus 
selection and renaming), and conversely, x can be simulated using N (plus 
renaming). Also, vr can be simulated by a series of tt's, and vr can be simulated 
by 71. To illustrate the latter, if we fix the type of r to {A, B, C}, then 7ryi(r) 
is equivalent to ttbt^c{'>^), and TTA^r) is equivalent to 7!'b,c{'>^)- However, these 
simulations are not "polymorphic," in the sense that they depend on the 
particular type assignment. 

As a matter of fact, we will see in Proposition ^ that polymorphic simu- 
lations of N using X, or vice versa, and of n using tt, or vice versa, do not 
exist. Hence, from a polymorphic point of view, our chosen set of relational 
algebra operators is non-redundant. 

3 Typable expressions 

The central notion of this paper is defined as follows: 

Definition 2 Expression e is called typable if there exists a type assignment 
T on Relvars{e) such that e is well- typed under T. 

A very simple example of an expression that is not typable is o'a=b{t''b,c{t"))- 
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Is typability a decidable property? This question is easily answered by the 
following lemma. We use the following notation. If T is a type assignment 
and v4. is a set of attribute names, then we denote by the type assignment 
defined by T|^(r) := T(r) fl ^. If e is an expression then we denote the set 
of all attribute names that explicitly occur in e by Specattrs{e). 

Lemma 1 If T \- e : t and A 2 Specattrs{e), then \- e : r H A. 

The proof is straightforward. As a consequence, in order to decide whether 
there exists a type assignment under which e is well-typed, it suffices to con- 
sider type assignments T with the property that T(r) C Specattrs{e) for 
every r. It follows immediately that typability is in NP. Whether or not it 
is in P, or is NP-complete, remains open. 

Of course, we are not satisfied simply by knowing whether or not a given 
expression is typable. What we really want is a clear, concise picture of 
exactly under which type assignments it is well-typed, as well as of what 
type the expression will have under each of these type assignments. (Note 
that there will in general be infinitely many such type assignments.) 

In the following, we will define the formalism of type formulas, which is 
specifically tuned towards this task. 

4 Examples of type formulas 

Consider the expression 

e = crB=c{{pA/B{r) Us)Mu). 

This expression is well-typed under exactly those type assignments T satis- 
fying the following two conditions: 

1. T{s)^{T{r)-{A})U{B}; 

2. C must belong to at least one of T(m), T(r), or T(s). 
Given such a T, the type of e then will equal T(s) U T{u). 
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All the above information is expressed by the following type formula for 

e: 



r 


: aia2 






s : 


: aia2 


1— > e 


: 010203 


u 


■ 0203 






A : 


r A -is 


A : 


u 


B : 


s A -ir 


B : 


: true 


C : 


(r s) A (r V s V ti) 


C : 


: true 



This type formula will the output of our type inference algorithm. It can be 
intuitively read as follows. Expression e is well-typed under precisely all type 
assignments that can be produced by the following procedure: 

1. Instantiate ai, 02 and 03 by any three types, on condition that they are 
pairwise disjoint, and do not contain A, nor B, nor C. 

2. Preliminarily assign type ai U 02 to r; ai U 02 to s; and 02 U 03 to u. 

3. In this preliminary type assignment, A must be added to the type of r, 
but must not be added to that of s; whether it is added to the type of u 
is a free choice. 

4. Similarly, B must be added to the type of s, not to that ofr, and freely 
to that of u. 

5. Finally, C must be added at least to one of the types ofr, s, and u, but 
if we add it to r we must also add it to s and vice versa. 

The type of e under a type assignment thus produced equals oi U 02 U 03, to 
which we must add B and C , and to which we also add A on condition that 
it belongs to the type of u. 

The symbols oi, 02 and 0,3 are called type variables. The attributes A, 
B and C, which are explicitly mentioned by the expression, are called the 
special attributes of the expression. The declaration of each relation variable 
as a string of type variables (where concatenation denotes union) provides 
the polymorphic basis of the type assignments under which the expression is 
well-typed. An attribute constraint for each special attribute then specifies 
(by a Boolean formula) the allowed extensions of the polymorphic basis types 
with that attribute. The declarations and constraints together form the type 
context; this is the left-hand side of the type formula. On the right-hand side 
we find the polymorphic basis of the output type, and again for each special 
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attribute, an output condition which specifies (by a Boolean formula) under 
which condition that attribute has to be added to the output type. 
Let us see two more examples. The type formula for the expression 

e = TTAir) - 7rA{{nA{r) x s) -r), 

which the reader will recognize as the textbook expression for the division 
operator, is: 

I— >■ e : 

s : a 

A : r A -IS A : true 

So r and s must have the same type except that r has an additional A (which 
s has not). The output type is always {A}. 

The type formula for the expression discussed in the Introduction, 

e = crA<5{r M s) M ((r x u) - v), 

is: 

V : 01020304 

r : 0103 

I— > e : O1O2O3O4O5 

u : 0204 
s : 030405 

A : {r y s) A {v ^ {r y u)) A -i(r Au) A: true 

The declarations specify exactly, in a manner similar to Venn diagrams, the 
conditions required on the types of the relation variables for the expression 
to be well-typed. 

5 Type formulas and type inference — For- 
mal definitions 

Before we can describe our type inference algorithm, we need precise def- 
initions of the underlying formalism. In what follows, we assume given a 
sufficiently large supply of type variables. 

5.1 Type contexts 

A type context is a structure consisting of the following components: 
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1. A finite set Relvars of relation variables. 

2. A finite set Typevars of type variables. 

3. A mapping decl from Relvars to 2^^'*'^'"^'"^, called the declaration map- 
ping. 

4. A finite set Specattrs of attribute names (called the special attributes) . 

5. A mapping constraint on Specattrs, assigning to each special attribute 
a Boolean formula over Relvars. 

Wc will usually denote a type context by the letter F and, when necessary 
to avoid ambiguities, will write Relvars{T), Typevars{T), etc. 

5.2 Semantics of type contexts 

Fix a type context F. The "models" of F will be type assignments on 
RelvarsiV) . We go from type contexts to type assignments via the notion of 
instantiation. An instantiation o/F is a mapping X on Typevars U Specattrs, 
such that 

1. X assigns to each type variable a type, such that 

• for different type variables ai and 02, 1(ai) and X(a2) are disjoint; 
and 

• for each type variable a and special attribute A; A ^ X{a). 

2. X assigns to each special attribute a subset of Relvars, such that for 
each special attribute A, X{A) |= constraint {A) . (Since constraint{A) 
is a Boolean formula over Relvars, and X{A) is a subset of Relvars, 
the meaning of X{A) \= constraint{A) is the standard meaning from 
propositional logic.) 

If some of the Boolean formulas in F are unsatisfiable, we call also F unsat- 
isfiable. In this case, F has no instantiations. 

Prom a type context F and an instantiation X of F, we can uniquely 
determine a type assignment T on Relvars, defined on each relation variable 
r as follows: 

r(r) := |J{X(a) | a e decl{r)} U {A e Specattrs \ r e X{A)}. 

We call this type assignment T the image of F under X, and conveniently 
denote it by X(F). 
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5.3 Type formulas 

A type formula now is a quadruple (F, e, Outvars, outatt), where 

1. r is a type context; 

2. e is a relational algebra expression with Relvars{e) = RelvarsiV), and 
such that SpecattrsiV) contains all the attribute names that are explic- 
itly mentioned in e. 

3. Outvars is a subset of Typevars(T); and 

4. outatt is a mapping on SpecattrsiV), assigning to each special attribute 
a Boolean formula over RelvarsiV) . 

The way we write down concrete instances of type formulas has already 
been illustrated in Section ^. 

5.4 Semantics of type formulas 

From a type formula (F, e, Outvars, outatt) and an instantiation 1 of F, we 
can uniquely determine the following type: 

{J(a) I a G Outvars} U {A G Specattrs \ 1(A) |= outatt (A)}. 

We call this type the output type of the type formula under X. 

We are now ready to define the following fundamental property of type 
formulas: 

Definition 3 A type formula (F, e, Outvars, outatt) is called principal for e 
if for every type assignment T on Relvars{e) and every type r, T h e : r if 
and only if there is an instantiation X of F such that T is the image of F 
under I, and such that r is the output type of the type formula under I. 

The main result of this paper can now succinctly stated as follows: 

Theorem 1 (Type inference) For every relational algebra expression e, 
there exists a principal type formula for e, which can be effectively computed 
from e. 

Note that if e is untypable, any unsatisfiable type formula (type formula with 
an unsatisfiable type context) is principal for e. 

We will substantiate our main theorem in the following sections. 
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6 Solving systems of set equations 



Type inference algorithms for programming languages typically work by 
structural induction on program expressions, enforcing the typing rules "in 
reverse," and using some form of unification to combine type formulas of 
subexpressions. In our case, relation types are sets, so we need a replacement 
for classical unification on terms. This role will be played by the following 
algorithm for solving systems of set equations. 

Fix some universe U. In principle U can be any set, but in our intended 
application U is the universe of attribute names. Assume further given a 
sufficiently large supply of variables. In our intended application, this role 
will be played by type variables. 

An equation is an expression of the form Ihs = rhs, where both Ihs and 
rhs are sets of variables.^ A system of equations consists of two disjoint sets L 
and R of variables, and a set of equations, such that every variable occurring 
at the left-hand side (right-hand side) of some equation is in L (in R). 

A substitution on a set S of variables is a mapping from S to the subsets 
of W. A substitution is called proper if different variables are assigned disjoint 
sets. A valuation of a system S consists of a proper substitution on L and a 
proper subsitution on R. A valuation {fL, Jr) is a solution of S if for every 
equation 

ai. . .am = hi. . .hn 

in S, we have 

/^(ai) U ■ ■ ■ U /L(a^) = /fi(bi) U ■ ■ ■ U /^j(fon). 

A symbolic valuation of S consists of a new set V of variables and a 
mapping g from LU Rto the subsets of V . Take some proper substitution h 
on V . Now define the following substitution hi on L: for any a & L, 

hda) ■.= [j{h{c) \ ceg{a)}. 

In a completely analogous way we also define the substitution on R. 
We call a symbolic valuation a symbolic solution of S if for every proper 
substitution h on y, the pair {hL,hR) is a solution of S, and conversely, 
every solution of S can be written in this way. So, a symbolic solution is a 
finite representation of the set of all solutions. 

note on notation: we will write a set {ai, . . . , a„} as oi . . . a„. 
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As a trivial example, consider the trivial system of equations where L — 
{a}, R = {b}, and without any equations. Any valuation is also a solution. 
A symbolic solution is given hy V = {ci, C2, C3} and 

g{a) = C1C2 and g{b) = C2C3. 

Indeed, note that we always work with proper substitutions, so ci, C2 and C3 
stand for pairwise disjoint sets. In particular, ci stands for a — b, C2 stands 
for anb, and C3 stands for b — a. 

Theorem 2 Every system of equations S has a symbolic solution, which can 
be computed from E in polynomial time. 

Proof. Let 

V := {a\ae L}U{b\be R}U{{a,b)\ (a, 6) e (L x R)}, 

and define the following symbolic valuation g with V as its set of variables: 
for each a & L, 

g{a) := {{a,b) \ b e R} U {a} 

and for each b & R, 

gib) :={(a,6)|aeL}U{6}. 

Then define the subset Vq QV as follows. An element c e y is in Vq if there 
is an equation 

ai . . . a„ = 61 . . . 6„ 

in S such that c belongs to one of the following two sets but not to the other: 

m n 

[jg{ai) and [Jgibj). 

i=i j=i 

Now consider the symbolic valuation g' with V := V — Vq as its set of 
variables, defined by g'{x) := g{x) — Vq. This g' can easily be constructed in 
polynomial time. We next show that g' is indeed a symbolic solution of E. 

Let h he a proper substitution on V . and let ai . . . = bi . . . be an 
equation. By definition of g', for every i G {1, . . . ,m} and every c G g'{a,j), 
there is a j G {!,... ,n} such that c G g'{bj), and vice versa, for every 
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j e {1, . . . ,n} and every c e g'{bj), there is an i e {1, . . . ,n} such that 
c e g'{ai). Hence, 

rrt m 

UU{^(^) I ^ e ^'(a,)} = U U{Mc) I c e ^'(6,)} 

hLiai) hR{bj) 

and thus {h^, hji) is a solution of S. 

Conversely, let {fL^fn) be a solution of E. Then define the following 
proper valuation h on for a & L, 

h(a) :=/4a)-U/«(i?); 

for he R, 

h(b) ■.^fn{b)-\Jh{Ly, 

and for (a, b) e {L x R), 

h{a,b) :=/4a)n/^(6). 

Clearly, for each a E L, 

fL{a) = \J{h{a,b) \ beR}Uh{a), 

and for each b e R, 

fRib) = [j{h{a,b)\aeL}Uhib). 

Put differently, 

/L(a) = U{^(c) I c e ^(a)} 

for each a, and 

= [j{h{c) I c e ^(6)} 

for each b. Since we want to show that g' is a symbolic solution, wc would like 
to show the last two equalities with g' instead of g. Since g'{x) = g{x) — Vq, 
it suffices to show that /i(c) is empty for each c e Vq, 

To see that these sets are indeed empty, we consider the three possibihties 
for an element of F to be in V^)- H a eVq with a E L, this means that there 
is some equation 

ai...am^bi...bn 
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where a is one of the ai, . . . , a^. Since {/l, /r) is a solution, 

m 

fL{a)c[jf^{b), 
so in particular, since h{a) C fL{ci), 

m 

h{a)c\Jfn{b). 
j=i 

However, by definition of h, h{a) is disjoint from each Hence, h{a) 

must be empty. 

Analogously we see that if b G Vq with b E R, then h(b) is empty. 
So finally, assume (a, 6) e Vq with (a, 6) e {Lx R). This means that there 
is either an equation of the form 

... a — . 

with b not occurring in the right-hand side, or of the form 

with a not occurring in the left-hand side. Let us focus on the first possibility 
(the second is analogous) and write the equation in more detail as 

...a...^bi...bm- 

Since (/l, is a solution, fiio)-, and in particular fL{ci')f^fR{b), is contained 
UjLi fR{bj)- However, since b is not among hi, ... , bm, and each fnibj) 
is disjoint from this can only be if fiia) H which is the same as 

/i(a, 6), is empty. ■ 

Let us sec a worked-out example of this solution method. Consider E 
with L = {ai, a2, as}, = 62, 63}, and the equations 

tti — bi and 02 = &i62- 

Prom the first equation we deduce that 

oi, (01,62), (01,63) 
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as well as 

bi, (a2,fei), (03,61) 
are in Vq. From the second equation we deduce that 

02, (^2,^3) 



as well as 

are also in Vq. So 



(ai,6i), 62, (03,62) 



V -Vo = {as, 63, (02, 62), (as, ^3)}, 

and the symbolic solution g' is given by 

g'{ai) = _ g'ihi) = 

g'{a2) = (a2, 62) _ ^''(^2) = (^2, 62) _ 
g'ias) = a3, (as, 63) g'ibs) = 63, (03, 63). 

If we rename the variables for added clarity, we obtain the symbolic solution 

tti = bi = 
a2 = ci 62 = ci 
03 = C2C3 63 = C3C4 

which can be interpreted as specifying that the only solutions to S are those 
where we assign the same set to 02 and 62, which is disjoint from the sets 
assigned to 03 and 63 (the latter two sets need not be disjoint), and where ai 
and 61 are empty. 



7 Principal type inference algorithm 

We are now ready to describe our algorithm. A computer implementation is 
available from the authors 1T7I . 



7.1 Two subroutines 

7.1.1 Extending a type formula with extra special attributes 

The following construction will be used as a subroutine in our algorithm. Let 
(r, e, Outvars, outatt) be a type formula, and let A be an attribute name not 
in Specattrs. By extending this type formula with A, we mean the following: 
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1. add A to Specattrs; 

2. define constraint (A) as 

(Vr)- V ( A A -^); 

r aeTypevars aedecl{r) a^decl(r) 

3. define outatt{A) as 

r I decl{r) C Ou^wars}. 
7.1.2 Conjugating two type contexts. 

This is another subroutine that will be used. Two type contexts Fi and r2 

are called compatible if (i) Typevarsi = Typevars2\ (ii) decli and decl2 agree 
on RelvarsiCl Relvars2; and (Hi) Specattrs^ = Specattrs2- By the conjunction 
of two compatible type contexts Fi and we mean the type context defined 
as follows: 

1. Relvars := Relvarsi U Relvars2- 

2. Typevars :— Typevars^ {— Typevars^)- 

3. decl := decli U decl2. 

4. Specattrs :— Specattrs [— Specattrs^. 

5. for each A e Specattrs, 

constraint{A) := constraint i{A) A constraint2{A). 

7.2 The algorithm 
7.2.1 Base case 

Our algorithm proceeds by induction on the structure of the expression. The 
base case, where e is a relation variable r, is trivial: 

r : a I— > r : a. 
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7.2.2 Union 



Let e — {e-iU 62). By induction, for i — 1,2, we have principal type formulas 
(FijCi, Outvarsi, outatti). We may assume that Typevarsi and Typevars2 are 
disjoint. We perform the following steps: 

1. For each A in Specattrsi not in SpecaUrs2, extend the type formula for 
62 by A. Conversely, for each A in Specattrs2 not in SpecattrSi, extend 
the type formula for ci by A. We now have SpecattrSi — Specattrs2, 
which we denote by Specattrs. 

2. Now consider the system of set equations E with L — Typevarsi, R — 
Typevars2, and the set of equations 

{decli{r) — decl2{r) \ r e Relvarsi fl Relvars2} 

U {Outvarsi — Outvars2}- 

Find a symbolic solution to this system, and apply it to the two type 
formulas. Denote the result of applying the solution to Outvars\ by 
Outvars; by the equation Outvarsi — Outvars2, this is the same as the 
result of applying the solution to Outvars2- 

3. The two type contexts Fi and F2 have now become compatible; in 
particular, they have the same set of type variables, which we denote 
by Typevars. Take their conjunction F. The resulting set of relation 
variables is denoted by Relvars. The resulting constraint mapping is 
denoted by constraint' . 

4. For each A in Specattrs, define constraint{A) as 

constraint' (A) A {outatti{A) outatt2{A)), 
and define outatt{A) as outatti{A). 
The result is a principal type formula (F, e, Outvars, outatt) for e. 

7.2.3 Difference 

The case e — {ei — 62) is treated in exactly the same way as the case e = 
(eiUea). 
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7.2.4 Natural join 

The case e = (ei IXI 62) is treated as tlie case e = (ei U 62), except for tlie 
following important differences in two of the steps: 

0. We omit the equation Outvarsi = Outvars2 from the system of equa- 
tions. We now define Outvars as the union of the results of applying 
the symbolic solution to Outvars i and Outvars2- 

For each A in Specattrs, constraint{A) is now the same as constraint' (A) , 
and outatt{A) is now defined as 

outatti{A) V outatt2{A). 

7.2.5 Cartesian product 

The case e = (ei x 62) is treated as the case e = (ei N 62), except for the 
following two differences, again in steps ^ and |^: 

0. In the computation of the symbolic solution, we put every pair (a, b) 
with a e Outvars I and b G Outvars2 by default in Vq (cf. the solution 
method described in the proof of Theorem 0). This will guarantee that 
the results of applying the solution to Outvars i and Outvars2 will be 
disjoint. 

^. For each A in Specattrs, define constraint{A) as 

constraint' {A) A -i{outatti{A) A outatt2{A)) . 

7.2.6 Selection 

Let e = ae(Ai,...,A„)(e')- 

1. Initialize the desired type formula 

(r, e, Outvars, outatt) 

to the principal type formula (F', e', Outvars' , outatt') for e' (which we 
already have by induction). 

2. For z = 1, . . . , n, if y4j is not yet in Specattrs, extend the type formula 
with Ai. 
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3. for i = 1, . . . ,n, replace constraint (Ai) by 

constraint (Ai) A outatt{Ai). 

4. For i = 1, . . . ,n, put outatt{Ai) := true. 

7.2.7 Projection 

For the case e = 7r^i,...,A„(e') we do the same as for the case e = (T0(Ai,...,a„){g')- 
In addition, we set 

• outatt{A) := false for each A in 

Specattrs — {Ai, . . . , An}, 

and 

• Outvars := 0. 

7.2.8 Renaming 

The case e = PA/sie') is treated similarly to the case e = <7e{A,B){e'), except 
that we treat B differently from A in step ^ as follows: 

Replace constraint{B) by 

constraint{B) A -^outatt{B). 

Furthermore, step ^ is changed as follows: 

Put outatt{A) := false, and outatt{B) := true. 

7.2.9 Projecting out 

Finally, the case e = Tr^le') is treated similarly to e = ae(^A){e'), with the 
exception that we set outatt{A) := false instead of true. 
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7.3 Example 



We illustrate the working of our algorithm on the expression 

e = (Tb=c {{PA/B{r) Us) M u) . 



ei 

62 



We will encounter only rather trivial systems of equations in doing this ex- 
ample; the reader is invited to try the example expression discussed in the 
Introduction for more interesting systems of equations. 

To find the type formula for ei, we start from the trival type formula 
r : a I— > r : a for r. Extending this type formula with A and B yields 

r : a ^ r : a 

A : r — > r A : r 
B : r ^ r B : r. 



Then we change the constraint r ^ r (or simply true) for A by true A r, or 
simply r, and we change the constraint for B by true A -ir, or -ir. Finally, 
we set outatt{A) to false and outatt{B) to true, yielding: 



r : a i— > Ci : a 
A : r A: false 

B : -ir B : true. 



To find the type formula for 62, we start from that for ei and the trivial 
formula for s, which we extend with A and B as 

s :h s : b 

A : true A : s 
B : true B : s. 

We now consider the rather trivial system of set equations with L = {a}, 
R = {b}, and the single equation a = b. The symbolic solution is obviously 
a — c,b — c. Applying this solution to the two type formulas simply changes 
both a and b into c. Conjugating the two type contexts yields the constraint 
r A true for A, which can be simplified to r, and the constraint -ir A true 
for B, which can be simplified to -ir. Then we add the conjunct false <-> s 
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to the constraint for A, yielding r A -is, and we add the conjunct true ^ s 
for B, yielding -ir A s. Finally, outatt{A) is set to false, and outatt{B) to 
true, yielding: 

r : c 

1-^ 62 : c 

s : c 

A : r A -IS A : false 
B : s A-T B : true. 

To find the type formula for 63, we start from the one for 62 and the 
trivial formula for u, which we extend with A and B as 

u : d ^ u : d 
A : true A : u 

B : true B : w. 

We now get the even more trivial system of set equations with L = {c}, 
R — {d}, and no equations, which has as symbolic solution c = C1C2, d = C2C3. 
We set Outvars to C1C2C3. Conjugating the two type contexts (after having 
filled in the solution) yields nothing surprising. Finally we set outatt{A) to 
false V u, which simpfifies to u, and set outatt{B) to true V u, or simply 
true, yielding: 

r : C1C2 

s : C1C2 ^ 63 : C1C2C3 
w : C2C3 

A : r A-is A: u 
B : s A-ir B : true. 

Finally, to find the type formula for e itself, we first extend the one for 
63 with C: 

r : C1C2 

s : C1C2 1-^ 63 : C1C2C3 
u : C2C3 

A : r A -is ^4 : -u 

B : s A-'r B : true 
C:(/7 C:rVsVM. 

Here, ip is the formula 

(r V s V u) — »■ ((r A s A -lu) V (r A s A u) V (-ir A -is A 

or simply r s. Then we add the conjunct true to the constraint for 
B (which has no effect), and the conjunct (r V s V ti) to the constraint for 
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C. Finally, we set outatt{B) = outatt{C) = true, yielding indeed the type 
formula we gave for e in Section ^ (modulo renaming of type variables). 

7.4 Correctness proof 

Extension of a type formula with extra special attributes (Section [7.1.1| ) is a 
heavily used subroutine in our type inference algorithm, and one might even 
go as far as saying that it is the only part of the algorithm whose correctness 
is not self-evident. Hence, the following lemma is of crucial importance: 

Lemma 2 The extension of any type formula, generated by our algorithm, 
with an extra special attribute, always produces an equivalent type formula. 

Here, equivalence naturally means the following. Consider two type formulas 
$1 and $2 whose type contexts Fi and F2 have the same Relvars, and let Ii 
(X2) be an instantiation of Fi (F2). We say that Xi andl2 are equivalent with 
respect to $1 and $2 if ^liXi) = ^2(1^2), and the output type of $1 under Xi 
equals the output type of $2 under X2. We say that $1 and $2 o'^e equivalent 
if for every instantiation of Fi there is an equivalent instantiation of F2, and 
vice versa. 

Now to the proof of Lemma 0. Let $ = (F, e, outatt, Outvars) be a type 
formula, and let $' = (F', e, outatt' Outvars) be its extension with the extra 
special attribute A. We have to show that $ and are equivalent. 

From $ to Let X be an instantiation of F. We have to find an equivalent 
instantiation X' of F'. 

If A ^ X(a) for every a G Typevars, we can simply put X'(a) := X(a) for 
each type variable a, 1'{B) := 1{B) for each special attribute B ^ A, and 
1'{A) := 0. In this case, it is clear that X' is a legal instantiation of F', that 
X(F) = X'(F'), and that the output type of $ under X equals the output type 
of under X'. 

If ^ G X(a) for some a G Typevars, we put X'(a) := X(a) — {A} for 
this a, and put T'{h) := X(6) for every type variable h ^ a. We also put 
T{B) := I{B) for each special attribute B ^ A. We finally put X'{A) := 
{r I a G decl{r)}. It is clear that X' is a legal instantiation of F', and that 
X(F) = X'(F'). To show that the output type of $ under X equals the output 
type of $' under X', we must show that if a G Outvars, then there exists an 
r G T'{A) such that decl{r) C Outvars. We will do this in Lemma |^. 
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From to Let T be an instantiation of V . We have to find an 
equivalent instantiation X of F. 

If I'{A) = 0, then we put X(a) := X'(a) for each type variable a, and 
2{B) := T\B) for each special attribute B ^ A. In this case it is clear that 
X'(r) — X(r), and that the output type of under X' equals the output 
type of $ under X. 

If T'{A) 7^ 0, wc know (because T'{A) |= constraint' {A)) that there 
exists an a G Typevars such that T'{A) = {r \ a E decl{r)}. Then we put 
X(a) := X'(a) U {A}, and X(6) := X'(6) for each type variable h ^ a. We 
also put T{B) := X'(i?) for each special attribute B ^ A. It is now again 
clear that X'(r') = X(r), and that the output type of under X' equals the 
output type of $ under X. ■ 

We still owe: 

Lemma 3 In any type formula generated by our algorithm, the following 
holds. Let a he a type variable in Outvars. Then there exists a relation 
variable r such that a e decl{r) and decl{r) C Outvars. 

Proof. By induction. The base case, r : a i— > r : a, is trivial. 

For the case e = (ei U 62) we reason as follows. Let g be the sym- 
bohc solution to the system of equations. Then Outvars = [J g{Outvarsi) = 
[j g{0utvars2) ■ Let c e Outvars. Then c e g{a) for some a e Outvarsi. 
By induction, we know that for some relation variable r, a & decli{r) and 
decliir) C Outvarsi. This implies that c e \J g{decli{r)) — decl{r), and that 
decl{r) C Outvars. 

For the case e = (ei M 62) we have Outvars equal to [J g{Outvarsi) U 
U5f((9?x^vars2), 5' again being the symbolic solution. Let c e Outvars. So, 
c e (J 5' ( Outvars 1) or c e (J 5'((9?x^?;ars2)- By symmetry we may assume that 
c e (J g{Outvarsi). Then c e g{a) for some a G Outvarsi. By induction, we 
know that for some r, a E decli{r) and decli{r) C Outvarsi. This implies 
again that c G decl{r) and decl{r) C Outvars. 

For the case e = (ei x 62), we can use exactly the same reasoning as 
for (ei 1X1 62) , because no particular properties of the symbolic solution have 
been used. 

The cases e = a, p and tt are trivial because they don't change Outvars 
and decl. The case e = tt is trivial because it sets Outvars to 0. ■ 

By induction on the structure of relational algebra expressions we can 
now prove that each case of our algorithm correctly produces a type formula 
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that is principal. The cases corresponding to unary operators are all proven 
correct in an analogous way; we treat the selection as an example below. 
The cases corresponding to binary operators heavily rely in addition on the 
correctness of our algorithm for solving systems of set equations, which we 
already proved correct in Section 

So, let e = cre(Ai,...,An){e')- Let the type formulas computed by our algo- 
ritm for e and e' be $ and respectively. By induction, we may assume 
that is principal for e'; we must show that $ is principal for e. 

By Lemma H, we may ignore step 2 of the algorithm and assume without 
loss of generality that for i = 1, . . . ,n, At is already in Specattrs' . More 
generally, we may assume that $ differs from only in that for i = 1, . . . , n, 

constraint (Ai) = constraint' {Ai) A outatt'{Ai) 

and 

outatt{Ai) = true. 

Now suppose Their. We must find an instantiation X of F such that T 
equals I(T) and r equals the output type of $ under X. Since T h e : r, we 
know that T h e' : r and that for i = 1, . . . ,n, Ai E r. Since $' is principal 
for e', we know furthermore that there exists an instantiation I' of T' such 
that T equals X'(r') and r equals the output type of $' under X'. We set the 
desired X simply equal to X', and verify: 

• X is a valid instantiation of F: Thereto, we must check for i = 1, . . . ,n 

that 2{Ai) \= constraint (Ai), or X\Ai) \= constraint' {Ai) A outatt' (Ai) , 
which is equivalent. That X'{Ai) \= constraint' {Ai) is trivial, by defini- 
tion. That T'{Ai) \= outatt{Ai) is also clear, since Ai E r and r equals 
the output type of under X'. 

• T = X(r): This is clear, since T = X'(r') and I{T) = I'{T'). 

• T equals the output type of $ under X: Since outatt differs from outatt' 
only in that the output constraints for the A are loosened, the output 
type of $' under X', which equals r, can only be a subset of the output 
type of $ under X. However, as every Ai is already in r, this subset 
relationship cannot be a strict one, and hence the two types are indeed 
equal. 

Conversely, suppose X is an instantiation of F, and let r be the output 
type of $ under X. We must now show that X(r) heir. To show this. 
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we note that T is a valid instantiation of F' (as the attribute constraints of 
r are tighter than those of F'). Hence, since $' is principal for e', we know 
that X(r) = X(r') h e' : r', where r' is the output type of $' under X. But 
this output type is the same as the output type of $ under X; indeed, outatt 
differs only from outatt' on the Ai, but all Ai are members of both types 
anyway (for $' this is because T{Ai) satisfies outatt'{Ai) by definition, and 
for $ this is trivial because outatt{Ai) = true). Hence, we have X(r) h e' : r. 
Since all the Ai are in r, we can conclude that X(r) h e : r. 

7.5 Complexity and typability 

Since every step of the induction can be implemented in time polynomial 
in the size of the output of its child steps, a rough upper bound on the 
time complexity of our algorithm is 2^°'"\ It remains open whether this 
complexity can be improved. Note that type formulas can be exponentially 
large; for example, the type formula for ri N (r2 1X1 (■ ■ ■ N r^) ■ ■ ■ ) uses 0(2'") 
different type variables. 

If the input expression was untypable, the algorithm will output an un- 
satisfiable type formula. Hence, an alternative way to check typability is 
to check satisfiability of the principal type formula. We do not have to wait 
until the end, however, to test satisfiability. In principle, as soon as an unsat- 
isfiable attribute constraint arises during type inference, the algorithm can 
stop and report that the expression is untypable. This is more useful, since 
it tells exactly where the expression breaks down. In a practical implemen- 
tation, one could do this by keeping the attribute constraints in disjunctive 
normal form. Doing this might actually have a better complexity than ex- 
pected, since the attribute constraints generated by the algorithm have a 
quite special form, which might be exploited. 

Note that unsatisfiable attribute constraints can only be generated in the 
following places: 

• Step ^ of cases U and — , and its adaptation for case x. A simple 
example of a type error that will be spotted in this place is 7r^(r)U7rB(s). 

• Step ^ of case a, and its analogues for vr, p, and tt. A simple example 
of a type error that will be spotted in this place is o'e{A){TTB{i"))- 

Since the above-mentioned steps in the algorithm are clearly only executed 
if there are special attributes, we thus have: 
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Proposition 1 Every expression without special attributes is typable. 
The reader might wonder about contrived examples such as 

(r X s) 1X1 (r U s), 

which has no special attributes, but does not seem typable. However, this 
expression is well-typed under the type assignment by which the types of r 
and s are empty. 

8 Polymorphic queries 

Usually, a query is defined as a mapping from databases of some fixed type 
to relations of some fixed type. We can define a polymorphic generalization 
of the notion of query, to allow databases of different types as input. Fix a 
schema S. 

Definition 4 1. Let T be a type assignment on S, and let r be a type. A 
query of type T — > r is a mapping from databases of type T to relations 
of type T. 

2. An input- output type family is a partial function F from all type as- 
signments on <S to all types. We denote the definition domain of F by 
domF. 

3. A polymorphic query of type F is a family (Qr)redomF of queries, where 
each Qr is a query of type T F{T). 

Viewed from this perspective, a type formula 7 with type context F is, 
of course, nothing but a specification of an input-output family F^: we have 
domF^ = {X(F) I X an instantiation of F}, and F^(X(F)) equals the output 
type of 7 under X. As a consequence, every relational algebra expression 
e expresses a polymorphic query of type F-y, where 7 is the principal type 
formula for e. 

The following notion now naturally presents itself: 

Definition 5 Two relational algebra expressions ei and 62 are polymorphi- 
cally equivalent if they express the same polymorphic query. 
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For example, the equivalence 



(TA=B{r X 7rA,B,c{s)) = r X crA=BTrA,B,c{s) 

is polymorphic, but the equivalence 

vrA(r N 7rA,B(s)) = 7rA(r M s) 

is not, as it is only valid under a type assignment T such that T(r) fl T{s) 
is a subset of {A, B}. 

We are now weaponed to return to the issue of non-redundancy already 
touched upon at the end of Section |^. 

Proposition 2 1. There is no expression not using IXI that is polymor- 
phically equivalent io r IXI s. We say that N is polymorphically non- 
redundant. The same holds for the operator x . 

2. There is no expression not using tt that is polymorphically equivalent to 
TTA{f^)- So, also TT is polymorphically non-redundant. The same holds 
for the operator n. 

Proof. Any expression e polymorphically equivalent to r N s must have 
principal type 

r : aia2 

I— > e : 010203. 

s : 0203 

Inspecting the principal type inference algorithm, we see that a type formula 
where Outvars contains the union of decl{r) and decl{s), where the latter two 
sets are different and have a non-empty intersection, can only be produced 
in the case of N. An analogous argument deals with x. 

As for 7r^(r), any polymorphically equivalent expression e must have prin- 
cipal type 

r : a 1— >■ e : 
A : r A : true 

Inspecting the principal type inference algorithm, we see that a type formula 
where Outvars is made empty, depending on some special attribute, can only 
be produced in the case of n. An analogous argument deals with n. ■ 

We can also show polymorphic inexpressibility results for the full lan- 
guage. For example: 
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Proposition 3 The semijoin r k s is not polymorphically expressible in the 
standard relational algebra. 

Proof. Suppose e is an expression polymorpliically equivalent to r x s. The 
principal type of e must be 

r : aia2 

t-^ e : aia2- 

s : 0203 

Since there are no special attributes, the operators a, p, tt, and tt cannot 
occur in e, except for tt^ (projection on the empty sequence of attributes). 
Now consider the type assignment T on {r, s} given by T(r) = {A, B} and 
T(s) = {B,C}, and the database D of type T defined by D(r) = {[A : x, 
B : y],[A : u, B : v]} and D(s) = {[B : y,C : z]}. Given T, the type of e is 
{A, B}. Using the above knowledge of e, we can see that in the value of e on 
D, either [A : x, B : y] and [A : u, B : v] both occur, or none of them occurs. 
However, this is in contradiction with the fact that e is equivalent to r k s. 
Hence, e does not exist. ■ 



9 Concluding remarks 

We have seen in the previous section that classical "derived" operators of the 
standard relational algebra can become primitive in the polymorphic setting. 
The same holds for many other such operators. Note that it is actually easy to 
extend our type inference algorithm to include semijoin and similar operators, 
so Proposition ^ should not be misinterpreted as a negative result. Rather, 
it indicates that the new issue arises as to how a basic polymorphic query 
language should be designed. This is an interesting direction for further 
work. 

As already mentioned in the Introduction, other obvious directions for 
further work include (i) applying type inference in practice to SQL rather 
than to the relational algebra; (ii) developing type inference in the context of 
semi-structured data models rather than the relational data model; or (iii) to 
do the same for object-oriented query languages such as OQL. When moving 
to the 00 context, one has to deal with the additional subtilities created by 
inheritance and subtyping. Current research in programming languages is 
giving these issues considerable attention. 

We have also ignored types on the level of individual attribute values, 
although such types are almost always present in practice, e.g., in SQL. For 
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example, for cr^="john" (^) to be well-typed it suffices for us that the type of 
r has an A-attribute. However, in reality, A must in addition be of type 
string. Incorporating types on the attribute value level only has an effect 
on the special attributes of an expression; it has no effect on its polymor- 
phic basis (recall the notion of polymorphic basis from Section ^). Hence, a 
type inference algorithm can still be based on solving systems of set equa- 
tions. When conjugating two type contexts, however (recall Section [7.1. 2|) , 
a unification on the value types associated to the special attributes has to 
be performed. A similar unification is induced by the natural join operator. 
Moreover, in the case of the selection operator, the selection predicate (which 
in our approach has remained abstract) will perform certain operations on 
certain special attributes, which will induce certain constraints on the value 
types associated to these attributes. In general, if the programming language 
in which we write selection predicates has a unification-based type system, 
then we can simply activate type inference for this system at the appropriate 
places. 
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